Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ssphwg/ssphwg-minutes-90may.txt

Text File | 1993-02-17 | 10.9 KB | 365 lines

CURRENT_MEETING_REPORT_



Reported by Joyce K. Reynolds/ISI and J. Paul Holbrook/ CERT

Agenda


  1. SSPHWG Charter
  2. Discussion on current security policy and relationship to the
     Security Policy Working Group (SPWG).
  3. Goals and directions of the SSPHWG (strawman proposal by J. Paul
     Holbrook)**.
     **NOTE: The strawman proposal is included at the end of this
     report.
  4. Needs and requirements.
  5. Timeframe for writing and submission for publication of the
     handbook.
  6. Review of plans/action items for next round of meetings.

     (a) Next meeting in Los Angeles, Tuesday, June 12th at
         USC/Information Sciences Institute.
     (b) Next IETF meeting in August at University of British Columbia.


Needs:

If there is a ``real threat'', who are the legitimate contact points:


   o technical
   o administrative

Phone Calls to Site(s) Three scenarios presented.  You are at your site
and a someone calls, stating that:

  1. They have a worm program, and would like permission to unleash it
     onto your site's network.
  2. They are the F.B.I., and are calling with the notification of
     intrusion into your site - F.B.I. suggests to keep the net open to
     watch the intruder.
  3. He is a hacker.  The hacker states that he has capability to crack
     your site's passwords, etc.

What procedures and policies should be in place so that you and your
site can deal with the above situations?


                          WHO YA GONNA CALL???

                   WHAT ARE THE LEGAL IMPLICATIONS??

                                   1






Overview

Who are the customers of our Handbook:

   o system administrators
   o site decision makers
   o site auditing the teams (?)

This Handbook will NOT be a guide on how to do:


   o risk assessment
   o contingency planning


This Handbook will promote and encourage people to hook into already
existing mechanisms, even if the site doesn't have security procedures
in place.  They may have emergency procedures and policies that could be
relevant.

Focus on things related to the network:

   o prevention
   o response
   o cleanup/followup

Assumptions:

   o network-connected
   o hosts
   o network devices
      -  terminal servers
      -  modems

Point out ``natural'' conflicts that will occur.

Physical security statement in this handbook (??)  We could point out
some of the risks.

   o What kinds of items should be in the handbook??
   o What issues should be addressed??



                                   2






List and discussion of issues


  1. Physical Security
  2. Site Security Boundary

       o Model :  definition of terms
       o Clues on what to do when you must cross organizational
         boundaries:
       o defining contact points
        (a) technical
        (b) administrative
        (c) response teams
        (d) investigative
       o Invisible/Visible
        (a) legal
        (b) vendors (products or providers)
        (c) press (policy and procedures)
        (d) service providers

  3. Updates
       o Procedures
       o Tools
  4. Education of Users
  5. Historical (collection of information) [collection and protection
     of evidence] [facts versus assumption or -----]
  6. Policy issues (Privacy)
  7. System Administrator's and Network Administrator's rights,
     responsibilities, AND liabilities
  8. Rights and responsibilities of Users
  9. Formal and Informal legal procedures

       o local security/police
       o FBI, Secret Service, etc.
       o Verification of contact

 10. Concept of ``Inter-net'', ``Outer-net''
       o circles of trust
       o ``firewall'' type concepts
 11. Procedures with working with response teams
 12. Participation in ``drills'' (?)
 13. ``Security'' of the communications lines (phones, etc.)
 14. ``Insider'' threats to the site
 15. Welcome banners (?)
       o is the access really authorized?
       o how do you know if you're authorized?
 16. Guidelines for acceptable use?
 17. Configuration management

       o passwords
       o bug fixes

 18. Tools


                                   3






       o preventive
       o response
       o inventory of tools?
 19. Education
       o legal
       o administrators
       o users (How do they deal with different kinds of threats and
         risks?
 20. Decision making authority

       o WHO is authorized to make what decisions?
       o WHAT authority do administrators have?
       o Layout for different cases for example:  call in legal
         investigator, or remove a user
       o ``License to hack'' MUST be authorized in advance??
       o Tiger Teams

 21. Emergency response
 22. Resources
       o other security devices
       o other books/lists/informational sources
       o form a subgroup?


SSPHWG volunteers will take on the task of developing a draft outline to
be presented at the next SSPHWG meeting at USC/Information Sciences
Institute in Marina del Rey on Tuesday, June 12th.  The SSPHWG will be
also be meeting at the next IETF plenary at University of British
Columbia.



                                   4






The following document was sent out to the SSPHWG mailing list several
days before the meeting.  Discussion of this document lead into the
other items noted in the minutes above.  There was no specific action on
this document, as it was intended mainly to make sure everyone agreed
with the general direction of the group.

GOALS AND DIRECTIONS OF THE SSPHWG -- A STRAWMAN by J. Paul Holbrook

THE NEED

Why is there a need for a handbook like this?  Looking at some of the
needs may help us understand what kind of product we want to produce.

As a member of the CERT, I've come in contact with many sites trying to
deal with computer security problems.  It's often a rude shock when they
discover someone has compromised their systems.  Even for sites that
have a good technical understanding of how to keep their systems secure,
there are often policy questions that they haven't addressed.  These
policy issues make dealing with the incident much more difficult.  Once
the incident is over, the push to 'make sure this doesn't happen again'
can result in policy made in hast; these policies can be more
restrictive and cumbersome than they need to be.

A computer security compromise has much in common with any other
computer 'disaster' such as an equipment breakdown or a fire.  You need
to have plans in place to prevent the problem, to deal with the problem
while it's happening, and to deal with the consequences after the fact.
Although it may seem over-dramatic to compare a security compromise to a
fire, the effect a malicious intruder could have on a site's operations
could be devastating.

Another way to look at the question of 'need' is to turn it around:  why
should any site (especially an academic site) care about creating a
computer security policy and procedures?


   o There is a real threat out there.  Intruders are using common holes
     to break into systems.  Sites need to understand what the threats
     and risks are.
   o Policies and procedures help you maintain the environment you want.
     Many organizations value open communication and sharing.  One
     security incident, and "the powers that be" could force a site into
     a more closed environment.  Policies show that you are aware of the
     problem and are taking steps to deal with it.
   o Policies help guide cost-effective decisions.  An academic site may
     decide that the cost of dealing with an incident doesn't warrant
     spending lots of time or money on defenses.  A business may make a
     different decision.
   o Policies And Procedures clarify responsibility and authority.  Do
     you have the authority to look at a student's files?  If so, do
     students know that?


                                   5






THE CUSTOMERS OF THIS WORK

Customers of what we're trying to do:


   o Systems administrators
   o Site decision makers
   o this includes administrators (in the traditional sense), managers,
     policy makers.  The people who have the 'official' word on what
     goes on at a site


Some people who are explicitly not customers:

   o Programmers
   o End users

We don't need to produce a recommended set of security policies and
procedures.  The IETF Security Policy Working Group (SPWG) is working on
that goal.  Instead, what we we will produce is a set of guidelines and
issues that policy makers will need to consider when they make their own
policies and guidelines.  This should be a tool to help people
understand the need for security procedures and policies and how to go
about creating them.  We can include suggestions where appropriate, but
much of the specifics of what a site decides to do will depend on the
local circumstances.  A university might make different choices about
security from a government research lab.

THE OUTPUT OF THE GROUP

We hope to produce a guide to the kinds of problems sites might face,
the issues they should consider, and guidelines to the kinds of steps
they can take to preventing and dealing with security problems.  This
handbook could be published as an RFC or an FYI.

Over time, this handbook might expand to become a more general reference
on site computer security.  Some of the things that might be included:


   o suggested policies and procedures (perhaps whatever the Security
     policy WG produces)
   o bibliographies of other information to read
   o pointers to tools to help with site security



                                   6






ATTENDEES

    Stan Ames                 [e-mail]
    Tom Bajzek                [e-mail]
    Pat Barron                [e-mail]
    Glee Cady                 [e-mail]
    Jeff Carpenter            [e-mail]
    John Cavanaugh            [e-mail]
    Andrew Cherenson          [e-mail]
    Richard Colella           [e-mail]
    Curtis Cox                [e-mail]
    Steve Crumb               [e-mail]
    Hunaid Engineer           [e-mail]
    James Galvin              [e-mail]
    Jonathan Goldick          goldick!b.psc.edu
    Martyne Hallgren          [e-mail]
    Greg Hollingsworth        [e-mail]
    Tracy Laquey              [e-mail]
    Marilyn Martin            [e-mail]
    Donald Morris             [e-mail]
    Gerard Newman             [e-mail]
    Marc-Andre Pepin          [e-mail]
    Marsha Perrott            [e-mail]
    Richard Pethia            [e-mail]
    Tod Pike                  [e-mail]
    Michael Reilly            [e-mail]
    Robert Reschly            [e-mail]
    Tim Seaver                [e-mail]
    Pat Smith                 [e-mail]
    Mary Stahl                [e-mail]
    Allen Sturtevant          [e-mail]
    C Wood                    [e-mail]
    Aileen Yuan               [e-mail]



                                   7